1. Field of the Invention
This invention relates to computer software, and more particularly to client-side load balancing of requests to a plurality of application server instances.
2. Description of the Related Art
RMI (Remote Method Invocation) is a way that a programmer, using the Java programming language and development environment, can write object-oriented programming in which objects on different computers can interact in a distributed network. RMI is the Java version of what is generally known as a remote procedure call (RPC), but with the ability to pass one or more objects along with the request. The object can include information that will change the service that is performed in the remote computer. The object parameter-passing mechanism may be referred to as object serialization. An RMI request is a request to invoke the method of a remote object. The request has the same syntax as a request to invoke an object method in the same (local) computer. In general, RMI is designed to preserve the object model and its advantages across a network.
RMI is implemented as three layers:                A stub (proxy) program in the client side of the client/server relationship, and a corresponding skeleton at the server end. The stub appears to the calling program to be the program being called for a service.        A Remote Reference Layer that can behave differently depending on the parameters passed by the calling program. For example, this layer can determine whether the request is to call a single remote service or multiple remote programs as in a multicast.        A Transport Connection Layer, which sets up and manages the request.        
A single request travels down through the layers on one computer and up through the layers at the other end.
IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of an industry standard, the Common Object Request Broker Architecture (CORBA). CORBA is an architecture and specification for creating, distributing, and managing distributed program objects in a network. CORBA allows programs at different locations and developed by different vendors to communicate in a network through an “interface broker.”
An essential concept in CORBA is the Object Request Broker (ORB). An Object Request Broker (ORB) is the programming that acts as a “broker” between a client request for a service from a distributed object or component and the completion of that request. ORB support in a network of clients and servers on different computers means that a client program (which may itself be an object) can request services from a server program or object without having to understand where the server is in a distributed network or what the interface to the server program looks like. Components can find out about each other and exchange interface information as they are running. To make requests or return replies between the ORBs, programs use the General Inter-ORB Protocol (GIOP) and, for the Internet, Internet Inter-ORB Protocol (HOP). IIOP maps GIOP requests and replies to the Internet's Transmission Control Protocol (TCP) layer in each computer.
The Java Naming and Directory Interface™ (JNDI) provides naming and directory functionality to applications written in the Java programming language. JNDI is designed to be independent of any specific naming or directory service implementation. Thus a variety of services—new, emerging, and already deployed ones—can be accessed in a common way. The JNDI architecture consists of an API (Application Programming Interface) and an SPI (Service Provider Interface). Java applications use the JNDI API to access a variety of naming and directory services. The JNDI SPI enables a variety of naming and directory services to be plugged in transparently, allowing the Java application using the JNDI API to access their services.
JNDI is a standard extension to the Java platform, providing Java technology-enabled applications with a unified interface to multiple naming and directory services. Part of the Java Enterprise application programming interface (API) set, JNDI makes it possible for developers to create portable applications that are enabled for a number of different naming and directory services, including: file systems; directory services such as Lightweight Directory Access Protocol (LDAP), Novell Directory Services, and Network Information System (NIS); and distributed object systems such as the Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI), and Enterprise JavaBeans (EJB).
The Common Object Services (COS) Name Server is the name server for storing Common Object Request Broker Architecture (CORBA) object references. It can be accessed from CORBA applications by using the COS Naming package (org.omg.CORBA.CosNaming). The JNDI/COS naming service provider implements the javax.naming.Context interface on top of the COS Naming package in order to allow applications to use JNDI to access the COS Name Server. JNDI can also be used to access other naming and directory services, in addition to the COS Name Server, thereby offering the CORBA application one interface for accessing different naming and directory services.
Many users of J2EE-compliant application servers frequently find themselves in need of a load balancing solution for RMI-IIOP requests made to the application server. These requirements typically stem from declining application throughput and performance when using a single instance of the application server process under load from RMI-IIOP client(s). Users typically write and test RMI-IIOP client applications working against a single application server instance (process). However, when this application is placed in a production scenario with a few hundred or thousand users sending requests to a single instance of the application server, performance problems and bad response times for the end users of the application may occur. These performance problems are typically due to the inability of a single JVM to scale to so many requests, inadequate sizing of the hardware that houses the application, etc.
A solution to the performance problems caused by using a single instance of an application may include deploying and running the application on multiple instances (processes) of the application server running on separate machines or on a single large machine with multiple CPUs (which may be referred to as application server clusters). Using this architecture, it is desirable to provide load balancing of client requests to the application server instances. While load balancing solutions and products (both hardware and software based) exist for HTTP requests, there are few solutions for load balancing RMI-HOP requests. These solutions typically have proprietary architectures and require vendor dependence for the end user. Therefore, it is desirable to provide a vendor-independent client-side load balancing mechanism for RMI-IIOP requests.